A computer system may include a delayed-transaction slave unit connected through a common pipeline (e.g., a Processor Local Bus (PLB)) to multiple master units. The slave unit may be able to support a first number of outstanding requests; whereas one or more master units may send to the slave unit a second, larger, number of requests (e.g., substantially concurrently). For example, the slave unit may be able to support a single outstanding read request; whereas two master units may attempt to read data from the slave unit. Optionally, an arbiter may be used to manage multiple pipelined requests originating from the multiple master units.
The first master unit may send a read request, which may be rearbitrated and accepted (e.g., acknowledged) by the slave unit, thereby becoming a delayed transaction. Based on the accepted read request, data may be transferred from the slave unit over the common pipeline to the first master unit. The data transfer typically involves a network delay time, e.g., a substantially constant network delay. During the network delay, the second master unit may send a read request, which may be rearbitrated and rejected (e.g., not acknowledged), since the slave unit is concurrently handling the read transaction of the first master unit.
Upon completion of the read transaction of the first master unit, the first master unit may send another read request, which again may be rearbitrated and accepted (e.g., acknowledged), thereby becoming another delayed transaction. During the network delay associated with that delayed transaction, the second master unit may send another read request, which again may be rearbitrated and rejected (e.g., not acknowledged), since the slave unit is concurrently handling the second read transaction of the first master unit
This sequence of operations may repeat, and the second master may be “starved” or “live-locked”, namely, may not receive data from the slave unit for a long period of time. This may occur, for example, if the time required for a network round-trip between the first master unit and the slave unit, is an integer multiple of the time required for an arbitration process (e.g., measured in PLB cycles). Once the data is read by the first master unit and the slave unit is freed to handle another request, the next transaction to be accepted is a further read request from the first master unit. The second master unit is thus “starved”, even though the arbiter operated according to a “fair” arbitration scheme.